Addressing Cyber Risk with a Unified Platform

Today, we’re going to be talking about key considerations for addressing cyber risk with a security platform.

Now, I’m going to talk today about the trade-offs between the platform, portfolio, and standalone approaches, as well as how to actually evaluate a security platform. And I want to close by talking a little bit about some keys to success and how you can really position yourself well when you’re thinking about what security platform you should be going with.

So a little about me before we get started. I’m Allie Mellen. I’m a computer engineer by training, and I got my start in security being a hacker. My first experience with the security community was hacking the Square Reader, turning it into a credit card skimmer, and then actually submitting that research to Black Hat. My talk got accepted. I flew out to Vegas and got to speak. I met a lot of amazing people in the community and basically fell in love with the industry immediately.

I was working on my own consultancy for engineering for a few years and ended up back in the security industry before winding up at Forrester, covering all things security operations, people, process, technology, and the SOC. Honestly all my favorite things. So, I’ve seen cybersecurity and technology from a number of different angles. And with that in mind, let’s dive in.

We’re going to start by talking about the trade-offs between different approaches to delivering security products today. And this is something that I see across multiple different markets, whether it’s XDR, EDR, security analytics, SOAR, or others. And the distinction here is actually very important to understand, in part because the terms are quite often misused, and it can be very difficult to know what you’re getting. Pretty much every security vendor claims to have a platform these days, but do they really? Let’s compare the different approaches.

The platform approach is a unifier between various tools the vendor offers with additional integrations with third-party technologies. This has the potential to bring tight integration between the vendor’s own offerings and a simplified user experience while still allowing for integrations with third parties.

The portfolio approach is where a vendor has various offerings that may be loosely coupled or more strongly coupled depending on the vendor, but no dependencies exist between them. This has the potential for strong interoperability and gives much more flexibility to use other tools.

And lastly, the standalone approach is where a vendor has a singular offering that they focus all of their efforts on. This requires strong interoperability with third-party offerings and has the potential to provide best of breed in addition to close partnerships with customers.

Now, if you’re particularly market savvy, you may have noticed one thing I did not include here is the suite approach. And that’s because ultimately, suites are very rare at this point in this industry. If a vendor does not have an integration with other vendors, whether it’s threat intelligence, SOAR integration, security analytics and integrations, or others, it’s much more difficult to get adoption in the enterprise market.

Now, let’s look at some of the drawbacks of each of these approaches. The drawbacks of the platform approach are the potential for the offering to bloat or for the vendor to become complacent in development. This is very dependent on the vendor, and not all platform vendors fall into this trap. When considering a platform approach, it’s best to have an understanding of the vendor’s vision and their roadmap for execution to make sure that you’re making the right decision.

The drawbacks of the portfolio approach are a potential for split focus with other offerings since the vendor has multiple. When considering a portfolio approach, it’s best to identify what offerings the vendor prioritizes and how they’re splitting up their R&D focus. Is it all stuck on one particular product, or do they spread it out evenly amongst them or semi evenly?

The drawbacks of the standalone offering are a potential need for deeper skills from the end users, the potential maintenance of using an independent offering, and the need for the end user to understand the product thoroughly and understand how to strategize its use with the rest of their tools. When considering standalone tools, it’s best to identify if your team has the skills to actually support independent offerings.

Now that we’ve gone through the potential benefits and the potential drawbacks, let’s dig into how we figure out what a product is going to do for us. I want to talk a little bit about how to actually evaluate security platforms so you can get the most value out of the offering. There are a lot of components that security leaders need to consider, and I’ve seen this firsthand as I’ve gone through Forrester’s wave evaluation process.

Now, I’ve identified three different things that are very critical for a security leader to understand and have insight into when they’re actually considering implementing a new technology or buying a new technology. And the way that I’ve actually developed these requirements is through my work defining XDR.

As part of that process, one of the things that came up quite frequently was, “hey, is this any different from security analytics?” And the answer is a resounding “yes.” But it’s very difficult to communicate how unless you have a thorough understanding of the different things that matter to practitioners and what they need to know as they go to buy a product.

And so to better communicate, I have decided to group these into three separate categories. The first is capability, which refers to what’s the technology actually doing. This is what we hear most about in marketing messages and in conversations with sales or in a high-level conversation about the technology. It covers what the technology does and how the technology addresses challenges that the practitioner has better than what they already have, and what the technology replaces, if anything.

The second is dependencies. This is the much less fun side of tech, the maintenance and behind-the-scenes operations of it. What dependencies exist? What does maintenance look like? And will the employees need to actually use the technology? How’s it going to be licensed? All of those really important things that we tend to shy away from when initially evaluating a product.

And lastly is time to value. When am I going to be able to use this technology? What’s the time to value? How do I deploy it? And what risks exist during the migration? All of these aspects are crucial when thinking not just about new markets, but also about how you’re actually evaluating the products that you’re considering adopting. You need answers to all of these questions, and honestly even more, that fall into these three categories.

So one thing that I didn’t mention here is something that’s really crucial from a security point of view. And I avoided getting into security specifics here because I wanted to give the overarching viewpoint of what you need to be considering when you are looking for a security analytics platform or a security platform generally. And so I want to get into something that is actually very security-specific that I have put a lot of work into making sure I prioritize as I go through this process.

And the way I want to introduce this concept is by talking about the incident response process. One of the most underrated aspects of incident response is the analysis and investigation portion. According to Forrester data, which is a survey of over 1,000 security decision makers, analysis or investigation, whatever you prefer to call it, takes the longest amount of time during the incident response process, more than anything else. And yet it’s often not represented in security products today.

If you think about marketing messages, a lot of them revolve around the detection aspects. To me, this shows a lack of data-driven understanding of what security practitioners struggle with during the incident response lifecycle, a lack of prioritization of the analyst’s experience with the tool itself. And this is pervasive in the industry. It’s so pervasive that my colleague, Jeff Pollard, and I researched a new term to talk about this and to communicate what security leaders need to see from their security tools.

So, when thinking about security platforms, practitioners should be thinking about and prioritizing what we call the analyst experience. I used to work with a CISO who said that analysts have the worst job in the world. He would say that quite often. And he was only really half joking. Ultimately, security analysts have a very difficult job, but it’s also a gateway into the security community and a security career for many individuals. And because of that, we need to make it better by improving the analyst experience.

Analyst experience is defined as security analyst’s perception of their interactions with a particular security product, service, and process across various work streams. It builds on a long history of user experience, customer experience and employee experience, but now with a focus on the security analyst themselves. And this isn’t just about better dashboards or sleeker interfaces. It’s about improving the analyst’s workflow across tools and processes.

There are five steps to analyst experience: discover, explore, classify, determine, and execute. These five steps can describe a plethora of different analyst workflows in the SOC, whether it’s detection, investigation, and response, or even a task like threat hunting. The point is to focus on improving the analyst’s workflow for each of these five steps to improve analyst experience.

And so when thinking about your strategy, consider analyst experience as a key piece of the equation. And further, consider it as a key criteria by which to evaluate vendors. How are they helping you achieve a better analyst experience, or how are they making it worse? This has implications far beyond the technology you are adopting. Having a good analyst experience means that you’re more likely to achieve better outcomes, whether it comes to stopping breaches or preventing incidents, and to retain security talent, because ultimately if the workflows are better, they’re going to enjoy what they’re doing more.

I want to close on a few keys to success when evaluating security platforms that I recommend. First, evaluate and validate individual offerings and potential joint value, especially when considering a platform. Think about what other tools you can integrate and have at your disposal. Oftentimes, I hear the value of multiple tools together, even those of the vendor’s own offerings, have a much greater value than when they’re separated out.

Second, consult with adjacent teams on what maintenance is going to be required and what use cases they might be able to use the same offering for as well. This is particularly applicable internally in the security team across different functions or with IT. Consider, just as we mentioned before, capabilities, dependencies, and time to value and all the questions that come with that.

And most importantly, prioritize the analyst experience. Let’s try to make this industry a little easier to thrive in, shall we?